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I.  INTRODUCTION 


"Be  alert,  the  world  needs  more  Lerts."  Anon 
1 . OBJECTIVES 

The  objective  of  this  report  is  to  develop  a methodology  for 
finding  an  optimal  transition  path  for  future  DCS  evolution.  The  total 

approach  is  based  on  a two-step  process.  The  first  step  involves  the 

# 

development  of  the  desirable  architecture(s)  for  a far-distant  future 
DCS.  The  second  step  involves  the  development,  analysis  and  evaluation 
of  alternative  transition  plans  which  bridge  the  gap  between  the 
existing  baseline  system  and  the  perceived  goals  of  future  systems. 
Selection  of  the  "best"  alternative(s)  therefore  implies  a joint 
optimization  problem  of  the  "best"  future  together  with  the  "best" 
transition. 

An  approach  for  solving  the  above  problem  can  be  developed  along 
the  following  steps: 

a.  Define  the  best  Future  System(s)  (FS). 

b.  Define  the  present  Baseline  System  (BS). 

c.  Select  several  Transition  Systems  {TS^  : i = 1,2,---}  which 
cost  C^  and  give  service  Sy  Define  "Distance"  between  TS^  and  FS  as 
TF^  and  between  BS  and  TS^.  ad  FT..  "Distance"  is  defined  as  a "measure" 
in  some  sense  which  indicates  the  shortfall  of  a suboptimal  solution 
versus  the  optimal  solution. 

d.  Define  Budget  Availability  (BA). 
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e.  {{S^.,  BT^."\  TF^-"^)}  such  that  C^.  <B^  where  is 

some  function. 

The  following  questions  occur  to  the  alert; 

a.  What  is  "best";  i.e.,  how  does  one  decide  that  FS^  is  "better 
than"  FS.? 

J 

b.  Exactly  what  is  meant  by  "service"  S^. ; can  it  be  measured? 

What  is  the  "Distance"  between  two  systems;  can  it  be  measured?  How 
should  the  set  {TS^.  : i =1,2,*--}  be  selected;  could  the  "best  possible" 
TS  be  omitted  from  the  set  by  oversight? 

c.  What  function  f(-»-»-)  is  proposed;  could  a different  choice  for 
f(-»*»*)  change  the  choice  of  TS^? 

The  objective  of  this  report  is  to  answer  question  a.  and  to 
indicate  a methodology  for  architectural  formulation  and  evaluation  of 
the  best  FS.  In  so  doing  we  find  hints  on  how  to  answer  the  other 
questions,  but  these  are  deferred  for  later  efforts. 

In  answering  question  a,  we  do  not  provide  a proposed  design  for  the 
DCS  in  detailed  terms.  What  we  do  is  develop  a methodology  which  can 
discover  and  quantify  the  tradeoffs  between  the  high  level  architectural 
issues  of  the  DCS  for  the  far- term.  Detailed  design  studies  are 
appropriate  only  for  near-term  DCS  planning. 

This  report  is  therefore  primarily  oriented  towards  far-term 
architectural  studies  of,  e.g.,  DCS  III,  a term  used  to  denote  the 
next  generation  DCS  beyond  1985.  To  present  the  approach,  however,  it  is 
necessary  to  "freeze"  time  at  the  present  and  then  consider  the  question: 
What  should  the  DCS  look  like  X years  from  now?  In  the  consideration  of 
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how  to  answer  that  question,  "X"  is  taken  to  be  far  enough  in  the  i 

future  to  avoid  being  overwhelmed  with  details;  i.e.,  we  are  not  j 

constrained  by  the  present  design. 

2.  THE  NEED  FOR  MEASUREMENTS  AND  MEASUREMENT  TECHNIQUES 

The  DCS  is  intended  primarily  to  meet  DOD  crisis  communication 
needs.  The  servicing  of  other  needs  under  benign  conditions  is  a 
secondary  consideration.  Thus  the  DCS  should  be  designed  to  assure 
survivable  communications  of  adequate  capacity  to  force  elements 
deployed  worldwide  under  wartime  conditions. 

In  efforts  to  meet  this  design  goal  various  attributes  are  posed 
as  desirable  for  the  DCS.  Among  these  are  flexibility,  security, 
interoperability,  reliability,  maintainability,  restorabil ity , etc. 

Cost  effectiveness  must  also  be  admitted  as  a design  goal  because  of 
the  need  to  get  maximum  comnunications  for  every  dollar  spent  under  a 
limited  budget. 

Because  of  the  limited  budget,  none  of  the  desirable  attributes 
for  the  DCS  can  be  regarded  as  absolute.  In  fact,  all  goals  are  subject 
to  tradeoff  under  economic  analysis.  This  seemingly  innocuous  statement 
is  at  the  source  of  the  DCS  management  and  engineering  problems.  In 
order  to  trade  off  different  design  attributes,  each  must  be  measured 
in  some  way,  either  objectively  or  subjectively.  The  relative  worths 
of  different  attributes  must  be  similarly  established. 
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It  is  quite  likely  that  the  relative  worths  of  DCS  attributes  will 
always  be  subjectively  established.  The  same  may  hold  for  the 
i measurement  of  some  individual  attributes  such  as  flexibility  and 

interoperability.  Nonetheless,  whenever  possible  an  attribute  should 

[ be  measured  quantitatively  and  in  such  a way  as  to  make  subjective 

\ 

f tradeoffs  easier.  As  an  analogy  to  the  guns  versus  butter  curve 

[ frequently  seen  in  economics  textbooks,  Figure  1 shows  a hypothetical 

[ survivability  versus  capacity  curve  at  fixed  dollars  for  a specific 

' DCS  architecture.  If  the  system  is  designed  to  maximize  a single 

attribute,  say  survivability,  then  a zero  capacity  (useless)  system 
results.  What  is  "reasonable"  is  a subjective  decision  depending  on 
the  relative  worths  of  the  different  attributes  in  the  minds  of  the 
I decision  makers.  Some  objective  decisions  can  be  made  from  such  a 

■ presentation.  This  is  discussed  next. 

The  analogy  of  Figure  1 can  be  extended  as  shown  in  Figure  2.  | 

Here  a family  of  curves  is  shown,  each  representing  a different 
; architectural  option  for  the  DCS.  From  such  a presentation  it  may  be 

possible,  in  principle,  (if  one  architecture  is  uniformly  dominant,  i.e., 
if  all  points  on  that  curve  lie  above  any  other)  to  conclude  that  a 
particular  architecture  is  preferable  regardless  of  the  desired  mix  of 
survivability  and  capacity. 

The  examples  given  above  are  hypothetical  and  oversimplified.  This 
i report  is  an  attempt  to  develop  the  outlines  of  a methodology  which  will 

relate  some  (not  all)  of  the  desirable  attributes  of  the  DCS  in  formats 
similar  to  Figures  1 and  2.  Whether  or  not  the  reader  agrees  with  the 
I 
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approach  suggested  herein  it  is  hoped  that  two  things  will  become 
evident.  The  first  is  the  need  for  quantitative  measurement  of  DCS 
attributes  wherever  possible.  The  second  is  the  need  for  a formal 
mechanism  relating  these  attributes  to  each  other  and  the  DCS  budget. 

Technical  planning  for  the  future  DCS  is  equally  as  important  as 
efficient  day  to  day  operations.  Without  well  defined  technical  plans 
and  a visible  and  therefore  improvable  framework  for  technical  planning, 
system  evolution,  cost,  and  services  cannot  be  efficiently  controlled. 

Since  planning  involves  uncertainties  proportional  to  the  lead  time,  it 
is  important  that  plans  be  updated  as  information  becomes  more  precise. 

Ideally,  technical  planning  should  be  a routine  affair,  repeated  to 
produce  updated  plans  whenever  a significant  change  occurs  in  the 
planning  factors. 

i 

Past  architectural  studies  of  the  DCS  have  indicated  in  broad  scope  j 

the  merit  of  a future  DCS  which  will  be  a predominantly  digital,  secure,  | 

f 

and  integrated  common  user  system.  The  cost  of  new  hardware  to  support 
such  a system,  the  design  of  the  hardware,  and  whether  or  not  user 
requirements  would  support  such  a system  at  any  projected  time  need  to  be 
adequately  addressed  in  architectural  studies.  Techniques  to  ameliorate 
these  difficulties  can  be  developed  if  the  problem  is  sufficiently  well 
stated. 

3.  REPORT  ORGANIZATION 

Section  II  develops  a description  of  the  DCS  and  a description  of 
the  technical  problem  in  abstract  terms.  Only  those  features  we  see  as 
essential  are  included.  Having  defined  the  problem  in  Section  II,  we 
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consider  ways  to  solve  it  in  Section  III.  The  proposed  approach  uses 
techniques  either  developed  or  being  developed  within  DCEC.  Section  IV 
concludes  the  report  with  a list  of  recommendations  for  further  work. 


II.  THE  DCS  TECHNICAL  PLANNING  PROBLEM 

"...  make  sure  that  people  think  they  have  a problem  before 
volunteering  a solution. "[1] 

1,  AN  ABSTRACT  DESCRIPTION  OF  THE  DCS,  OUTSIDE  VIEW 

The  DCS  can  be  externally  characterized  by  demands  for  service  and 
threats  against  service  (see  Figure  3).  The  small  square  boxes 
represent  user  installations  which  place  demands  for  connections 
through  the  DCS  to  other  user  installations.  The  cut  (crack)  in  the  DCS 
represents  a possible  threat  to  service,  i.e.,  an  inability,  for  what- 
ever reason,  to  connect  users  on  opposite  sides  of  the  cut. 

The  user  installations  shown  in  Figure  3 can  be  characterized  in 
a number  of  ways:  by  geographical  location,  by  national  affiliation, 
by  military  department,  or  by  other  special  communities  of  interest.  The 
relevant  characterizations  from  an  overall  DCS  design  point  of  view  are 
geographical  location,  user  community,  and  user  need  lines.  Recalling  that 
the  primary  DCS  objective  is  to  provide  crisis  communications,  the  problem 
then  is  to  predict  that  collection  of  user  communities  and  that  set  of 
geographical  locations  within  each  community  which  will  need  such  service. 
Let  the  collection  be  designated  as  U,  a collection  of  sets  U|^: 

U = {Ui,  U2,  • • • ’^1^} 

U|^  = {(i,  x^,  y^)  : i = 1,  2,  •••,  I,^};  k = 1,  2,  •••,K 

where 

k : user  community  index 

i : user  location  index 
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- 1 

i 

j 

i 

• geographical  coordinates  of  the  i—  user  location  ! 

Each  user  location  is  further  characterized  by  that  (possibly 

K i 

improper)  subset  of  U|^  with  which  it  needs  to  communicate  and  by  j 

the  type  and  amount  of  communications  required.  This  allows  inter- 
operability requirements  to  be  explicitly  stated.  The  types  of 
communications  required  are  typically  clear  voice  (CV),  secure  voice  (SV), 
interactive  data  (ID),  narrative/record  data  (NRD),  and  facsimile  (F). 

AJnounts  are  given  in  Erlangs  or  bits/busy  hour  (BH).  The  probleir  then 
is  to  predict  a set  of  crisis  communications  requirements  matrices  for 
each  community. 

'^cv,^  " ^“ij^k  ’ = '•’2. 

«sv,  = ^-j^k  ...,K 

'^id^  " " ■'>2’ 

*^nrd|^  ~ ^'^ij^k  ; k = 1,2,  •*•,< 

» k = 1,2,  •••,K 

where 

i,j  : user  location  indices;  i,j  = 1,2  •••,N 

ojj  : Erlangs/BH  of  clear  voice  communications  from  location 
^ i to  location  j 

: Erlangs/BH  of  secure  voice  i to  j 
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Y^j  ••  Bits/BH  of  interactive  data  i to  j 
o^j  : Bits/BH  of  narrati ve/record  data  i to  j 
P|j  : Bits/BH  of  facsimile  data  i to  j 

These  communications  requirements  matrices  will  turn  out  to  be  slowly 
varying  functions  of  time  in  response  to  changing  levels  of  international 
tension,  technological  capability,  etc. 

It  is  reasonable  to  assume  that  in  the  event  of  war  some  part  of  the 

i I 

adversary's  resources  will  be  devoted  to  disrupting  the  DCS  as  well  as 

against  individual  user  installations.  The  design  of  the  DCS  should  | 

take  this  into  account.  Thus  additional  prediction  problems  are  raised. 

' 

What  subset  of  user  installations  is  likely  to  be  attacked  and  how  will  ' 

this  change  the  crisis  communications  requirements  matrices?  (This 

allows  consideration  of  flexibility  issues.)  What  elements  of  the  DCS 

are  likely  to  be  attacked  and  how  will  this  change  the  ability  of  the 

system  to  handle  communications  requirements  (survivability  issues)? 

A conservative  approach  to  the  first  question  would  be  to  construct 

J 

I 

composite  upper  bounding  requirements  matrices.  For  each  type  of  service  ; 

the  i,j  entry  in  the  composite  matrix  would  be  the  maximum  over  some  set  j 

of  conceivable  scenarios.  As  for  the  second  question,  it  can  be  shown  ] 

that  the  answer  depends  on  the  value  of  particular  communicating  pairs, 
the  reliability  of  elements  within  the  DCS,  the  structure  of  the  DCS,  the 
adversary's  knowledge  of  these  factors,  and  the  resources  devoted  to  the 

attack  [2].  A useful  technique  in  addressing  this  problem  is  to  adopt  a 
gaming  approach  in  the  initial  DCS  design  work. 
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2.  AN  ABSTRACT  DESCRIPTION  OF  THE  DCS,  INSIDE  VIEW 


The  DCS  can  be  internally  characterized  by  hardware  devices  and 
groupings  of  devices  used  to  satisfy  communications  requirements. 
Associated  with  the  hardware  devices  are  trends  both  in  technological 
capability  and  cost.  Cost  considerations  naturally  involve  allocation 
of  a constrained  total  budget  as  well  as  amortization  of  the  present 
inventory  of  equipments, and,  once  again,  predictions  of  what  the  future 
holds. 

4 

One  way  of  depicting  the  range  of  alternatives  for  the  DCS  in  the 
near,  mid  and  far  term  is  shown  in  Figure  4.  Another  apparently  popular 
view  is  that  the  figure  depicts  the  planning  problem,  in  the  form  of  a 
tree  structure,  for  the  DCS.  No  attempt  has  been  made  to  fill  in  all  the 
possible  branches  of  the  tree;  only  enough  is  presented  to  show  the  major 
features.  The  problem  with  the  tree  structure  is  that  it  tends  to  seduce 
one  into  forming  erroneous  conclusions.  This  is  discussed  below. 

The  figure  is  laid  out  in  a number  of  levels.  At  the  top  (level 
0)  is  a single  node  labeled  "DCS  architectural  alternatives."  This 
node  branches  to  a number  of  nodes  immediately  below  in  what  will  be 
referred  to  as  level  1.  In  turn,  each  node  on  level  1 branches  to 
several  nodes  on  level  2,  etc.. 

The  nodes  of  level  1 represent  different  system  partitioning 
alternatives  for  the  DCS  in  terms  of  the  degree  to  which  the  users  of  the 
system  are  integrated.  The  nodes  of  level  2 represent  the  generically 
different  switching  methods  which  could  conceivably  be  used  to  realize 
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the  partitioning  alternatives.  These  methods  are  circuit  (C),  packet 
(P)  and  circuit/packet  (C/P).  The  nodes  of  level  3 represent  the 

different  switchina  concepts  which  could  be  used  to  realize 
• a particular  switching  method.  The  examples  shown  in  Figure  4 are 'SENET 
[3]  and  SENET  Virtual  Circuit  (SVC)  which  fall  under  the  switching 
method  of  C/P.  On  level  4 the  nodes  represent  the  possibilities  for 
different  switch  architectures  to  realize  a given  switching  concept.  At 
level  5 the  nodes  represent  the  hardware  and  software  alternatives 
to  realize  a given  switch  architecture,  etc.  In  sum,  the  tree  structure 
represents  one  technique  for  aggregation  of  descriptive  features  of 
the  DCS  and  displays  the  range  of  choices  in  planning  the  DCS. 

The  tree  structure  indicates, , but  does  not  show  clearly,  the 
coupling  between  decisions  made  at  different  levels.  For  example,  a 
partitioning  study  at  level  1 cannot  be  properly  conducted  without 
costing  information  related  to  transmission,  switching, and  access 
equipment  for  the  total  DCS.  The  costing  information  can  only  be  found 
by  a network  design  study  for  the  total  DCS  conducted  at  level  2.  Even 
at  level  2 the  costing  information  is  likely  to  be  quite  inaccurate, 
particularly  with  regard  to  switching  costs,  in  the  absence  of  a network 
design  study  at  level  3 for  the  purpose  of  inferring  switch  functional 
design,  loading, and  cost.  Note,  however,  that  if  network  design  studies 
are  conducted  at  levels  2 or  3,  then  partitioning  studies  at  level  1 
have  been  explicitly  performed  in  considerable  detail. 
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Froin  the  foregoing  it  can  be  seen  that  architectural  development/ 
design  Is  a very  complex  problem  involving  many  closely  coupled  factors. 

Good  decisions  are  not  possible  by  looking  ahead  only  one  level  at  a 
time  (as  the  tree  structure  may  tempt).  Ideally,  one  would  like  to 
examine  every  node  in  the  last  level  of  the  tree  to  make  the  optimum 
decision.  Unfortunately,  the  proliferation  of  branches  makes  this 
impractical;  in  fact,  the  possibility  of  arriving  at  the  same  end  point 
in  the  tree  by  taking  different  paths  may  make  such  an  approach  inadequate 
on  the9retical  grounds.  Consequently,  an  approach  based  on  network 
analysis  and  aggregation  of  descriptive  features  of  hardware  is  suggested. 

The  network  analysis  approach  is  discussed  in  section  III;  hardware 
features  are  discussed  in  the  following  paragraphs. 

Regardless  of  the  particular  mettiodology  used  to  design  the  DCS, 
data  on  the  hardware  devices  used  to  construct  the  system  are  required. 

The  fundamental  difficulty  in  technical  planning  of  the  DCS  is  balancing 
the  cost  and  the  capability  of  the  total  system.  This,  coupled  with  a 
view  of  the  DCS  as  being  basically  a (family  of)  connecting  network(s), 
suggests  the  following  classifications  and  data  requirements  for  DCS 
hardware  as  used  in  the  architectural  development  methodology. 

a.  Base  Communications.  Terminal  equipment  and  local  switches  are 
located  within  the  user  installation  and  are  not  considered  as  part  of 
the  DCS.  However,  since  they  represent  the  ultimate  sources  and  sinks  of 
information  handled  by  the  DCS,  a minimal  characterization  is  necessary. 

All  terminal  equipments  within  a particular  user  installation  may  be  homed 
on  one  or  more  local  switches  which  represent  the  information  sources  and 
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sinks  for  the  DCS.  The  necessary  information  regarding  these  was 
developed  in  the  requirements  matrices  of  subsection  1. 

b.  Terrestrial  Grid.  The  terrestrial  grid  is  composed  of  concen- 
trators, backbone  switches,  and  links  connecting  these  to  each  other 
and  to  local  switches.  Concentrators,  as  the  name  implies,  may  have 
several  local  switches  homed  on  them  as  well  as  being  homed  on  other 
concentrators.  (We  also  allow  the  possibility  of  switching  by  a 
concentrator.)  In  turn, backbone  switches  may  have  several  concentrators 
homed  on  them.  The  structure  and  hierarchical  definition  of  a survivable 
and  economic  system  of  adequate  capacity  can  be  deduced  by  applying 
network  design  tools.  This  will  be  further  discussed  in  section  III. 

The  necessary  data  to  drive  the  tools  are: 

(1)  An  initially  assumed  set  of  potential  concentrators  with 
their  characterizations,  i.e.,  a set  of  sextuples: 

C = = 1,2,  -".L} 

where 

I : an  index 

f„  : functional  characterization  of  the  concentrators; 
i.e.,  voice,  data  or  integrated 

c^  : throughput  (or  capacity)  characterization 

d„  : cost  (dollars)  characterization.  This  is  a prediction, 
in  the  form  of  a Cost  Estimating  Relationship  (CER), 
which  depends  on  capacity,  function  and  number  of 
terminations.  O&M  costs  may  also  be  included. 
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L = {([i.j],  f, 


where 


[i.j]  : indices  for  the  hardware  devices  at  the  two 

endpoints  of  a bidirectional  link  from  i to  j. 
[•,•]  becomes  (•,•)  if  the  link  is  undirectional . 


The  remaining  parameters  have  the  same  meaning 
as  before. 


c.  Satellite  Grid.  It  is  unrealistic  to  consider 
satellite  communications  as  a separate  issue.  Rather,  the  satellites  and 
ground  terminals  should  be  treated  as  two  more  sets  of  hardware  in  a 
total  system  context.  Such  a view  allows  the  network  design  process  to 
treat  the  "mix  of  media"  problem  as  a systems  problem.  The  necessary 
data  are: 

(1)  An  initially  assumed  set  of  satellites  and  their 

characterizations.  The  same  parameters,  with  the  exception  of 
location,  are  needed  as  before. 
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s = {(n,  f^,  c^,  d^)  : n = 1,2.  •••.N}. 

(2)  An  initially  assumed  set  of  satellite  ground  terminals 
and  their  characterization. 

G = {(t,  f^,  c^,  d^,  x^,  y^)  : t = 1,2, 

Economics ’has  been  referred  to  often  in  the  preceding 
discussion.  Demands  for  service  are  satisfied  by  a system  of  hardware 

4 

devices.  The  system  cost  is  the  sum  of  all  hardware  device 

costs.  However,  the  ability  of  the  system  to  satisfy  demands  for 
service  is  not  the  sum  of  all  hardware  device  abilities.  This  fact, 
along  with  the  observation  that  the  total  system  cost  is  constrained 
by  the  DCS  budget,  creates  an  economic  optimization  problem  in 
technical  planning  of  the  DCS. 

The  problem  is  compounded  by  the  fact  that  the  exact  DCS  budget 
is  not  known  for  future  years.  It  must  be  predicted.  Thus  we  have  the 
additional  problem  of  formulating  an  economic  constraint,  D,  as  a 
function  of  time,  national  mood,  etc.;  i.e., 

D = f (T,-). 

Even  given  D, other  economic  problansmust  be  solved.  One  is  the 
allocation  of  D to  different  types  of  communications  services  and/or 
user  communities.  It  is  clear  that  if  more  money  is  allocated  to,  say, 
subsystem  A,  then  less  money  can  be  allocated  to  subsystem  B;  thus  the 
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budget  allocation  problem  couples  the  DCS  problem  even  when  physically 
independent  networks  are  assumed.  See  for  example  the  multidivisional 
problem  in  reference  [4]. 

Still  another  economic  factor  is  the  amortization  rate  of  equip- 
ment currently  in  service.  The  best  technique  of  assigning  economic 

lifetimes  to  hardware  and  systems  is  not  clear.  What  is  clear  is  that 

0 

equipment  in  the  field  today,  or  to  be  put  in  the  field  tomorrow, 
represents  an  enormous  DCS  investment.  The  sheer  size  of  this  invest- 
ment has  a significant  impact  on  the  economic  feasibility  of  an  other- 
wise excellent  plan.  Thus,  if  a given  plan  requires  the  premature 
retirement  of  large  amounts  of  DCS  hardware,  it  will  not  likely  be 
acceptable. 

3.  AN  ABSTRACT  STATEMENT  OF  THE  DCS  ARCHITECTURE  FORMULATION/EVALUATION 

PROBLEM 

The  preceding  subsections  have  been  developing  pieces  of  the  overall 
DCS  problem.  In  this  subsection  these  pieces  are  collected  and  organized 
into  a single  time  phased  problem.  This  single  problem  depends  on 
solving  a sequence  of  problems  in  estimation  theory  which  involve 
prediction  theory  and  probability  theory.  Network  analysis,  involving 
graph  theory  and  optimization  theory, is  then  applied  to  the  results  of 
the  estimation  problem.  Next,  management  is  involved  in  making 
subjective  tradeoff  decisions  on  the  mix  of  attributes  possible  within 
economic  constraints. 
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As  alluded  in  the  introduction,  time  phasing  enters  the  problem 
in  the  following  way.  In  far  term  architectural  development  we  would 
like  to  discover,  with  as  much  precision  as  possible,  what  the  future 
DCS  should  look  like.  By  far  term  we  simply  mean  a future  time 
sufficiently  advanced  so  that  the  architecture  is  not  influenced  by  the 
present  inventory  of  DCS  hardware  and  its  amortization  rate.  Once  the 
necessary  outlines  of  the  far-term  DCS  architecture  are  established, 
one  needs  to  solve  a second  problem  which  takes  into  account  the 
pr^esent  equipment  inventory.  This  is  the  mid-term  planning  problem  and 
can  be  stated  roughly  as  follows.  Given  the  present  DCS  design  and  some 
desirable  far-term  DCS  architecture(s) , what  mid-term  DCS  design  is  best 
suited  both  for  transitioning  from  the  present  design,  and  towards  one 
of  the  far-term  architectures.  Finally,  there  is  the  near-term,  or 
day-to-day,  problem  of  maintaining  the  efficiency  of  the  present  design 
as  it  evolves  into  the  future. 

The  mid-term  and  near-term  planning  problems  are  seen  as  successive 
refinements  of  the  far-term  architectural  development  problem.  That  is, 
as  the  planning  lead  time  decreases,  predictions  on  demands  for  service, 
technology  capacility  and  cost,  design  constraints,  etc.,  become  more 
accurate  and  allow  a more  detailed  definition  of  the  DCS  through  the  same 
basic  technical  planning  mechanism.  Consequently,  only  the  far-term 
problem  is  developed  since  it  contains  the  essential  features  without 
becoming  overly  burdersome  in  details. 
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a.  DCS  Architectural  Issues.  DCS  planning  involves  several  "high 


level  issues"  which  drive  more  detailed  considerations.  A short  dis- 
cussion of  these  issues  follows. 

(1)  Partitioning  Alternatives.  One  architectural  issue  is  that 
of  partitioning.  This  can  be  displayed  in  two  dimensions:  service  type 
and  user  community.  Figure  5 shows  an  example.  The  DCS  is  a connecting 
netvrork  (or  family  of  networks)  designed  to  meet  the  need  of  each  user 
community  for  each  type  of  service  required.  Suppose  there  are  I service 
types  and  K user  communities.  Then  there  are  a maximum  of  I-K  demands 
placed  on  the  DCS.  A partitioning  alternative  is  a choice  of: 

(a)  How  many  physically  independent  connecting  networks 
will  be  built  to  meet  all  demands.  Cal.l  this  number  NN;  then 

m = 1,2, 

is  the  range  of  possibilities. 

(b)  A set  of  assignment  rules  which  maps  the  I-K  demands 
onto  the  NN  networks. 

Clearly  the  number  of  partitioning  alternatives  for  the  future  DCS  is 

very  large.  How  does  one  decide  which  alternative  is  best?  (See  subsection  b.) 

(2)  Switching  Technology  Alternatives.  Switching  technology 
issues  of  the  DCS  can  be  displayed  in  a single  dimension,  the  generic 
switching  concept,  as  shown  in  Figure  6.  The  choice  here  is  not 
necessarily  dictated  by  prior  choice  of  partitioning  alternatives  since 
it  is  conceivable  that  data  can  be  handled  by  circuit  switching  or  voice 


22 


Army  Navy  Force  WWMCCS  NATO  . . 


service  type 

4 


user  community 


Figure  5.  Partitioning  Alternatives  Matrix 


by  packet  switching  [5].  How  does  one  decide  which  alternative  is  best? 
How  do  the  choices  of  partitioning  and  switching  technology  alternatives 
interact?  If  a partitioning  alternative  involves  more  than  one  network, 
should  several  switching  technologies  be  used?  (See  subsection  b.) 

(3)  Hierarchical  Alternatives.  Hierarchical  alternatives  for 
the  DCS  cannot  conveniently  be  displayed  on  a page  since  this  issue 
covers  an  astronomically  large  number  of  possible  ways  to  connect  the  DCS 
users.  In  general  terms,  it  can  be  argued  that  a fully  distributed  network 
is*  best  from  a survivability  point  of  view,  but  such  networks  are,  in 
general,  not  economical.  Conversely,  a network  with  many  hierarchical 
levels  is  best  from  an  economics  point  of  view,  but  such 

networks  are  less  survivable.  Exactly  what  structure  is  best?  Is  the 
choice  of  structure  influenced  by  prior  choice  of  partitioning  alternative? 
Does  the  choice  of  switching  technology  have  an  impact?  (See  subsection  b.) 

(4)  Mix  of  Media.  The  mix  of  media  problem  of  the  DCS 
involves  a tradeoff  of  communications  dependence  on  the  terrestrial  and 
on  the  satellite  resources  of  the  DCS.  There  is  no  realistic  way  to  treat 
these  resources  independently  in  a system  context,  and  so  this  issue  is 
properly  a part  of  the  hierarchical  issue  above. 

b.  Objectives  of  Technical  Planning.  Several  questions  were  posed  in 
subsection  3, a,  above,  related  to  "best"  choices.  A technique  for  making 

quantitative  measurements  of  differing  alternatives  is  necessary  before 
it  can  realistically  be  said  that  one  is  superior  to  another.  It  is 
therefore  necessary  to  agree  on  some  measurable  attribute  of  the  DCS  and 
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decision  rules  for  making  choices  among  alternatives.  The  measurable 
attribute  will  be  called  a performance  characteristic. 

Any  number  of  performance  characteristics  related  to  the  attributes 

in  section  I could  he  proposed.  We  propose  the  following. 

Let  a DCS  alternative  be  defined  by  a partitioning  choice  and  switching 
technology  choice(s)  (from  subsection  3, a).  Within  each  DCS  alternative  there 
are  a great  number  of  possibilities  for  specific  connecting  networks 
composed  of  the  hardware  devices  of  subsection  2.  Each  possible  family  of 

i 

connecting  networks  will  be  called  a design.  Each  design  is  a detailed 
accounting  of  such  things  as  hierarchical  structure,  mix  of  media,  numbers, 
types  and  locations  of  hardware  devices,  interconnecting  links  and 
capacities,  etc.  Each  design  within  a specific  DCS  alternative  can 
satisfy  the  service  demands  in  a measurable  way.  In  fact,  there  are  at 
least  two  distinct  and  useful  measurements  that  can  be  made.  One  will  be 
called  the  utility  under  benign  conditions  the  second  will  be  called 
the  utility  under  attack  U, . These  are  defined  as  follows: 


“b  ■ f 


^i,j,k^  “i,j,k 


where 

“i  i k ■ P'^®‘^^cted  service  demand  from  user  i to  user  j in 

community  k.  (Note  that  conversions  from  Erlangs  to  bits/BH 
have  to  be  made.) 

P.  . . ; Grade  of  service  (GOS)  for  voice  traffic  or  the  fraction  of 
dj  j |(  that  must  be  discarded  to  obtain  acceptable  delays 
for  data  traffic. 
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Now  imagine  that  an  intelligent  adversary  attacks  the  design,  removes 
exactly  W elements  and  chooses  that  set  of  W in  a way  to  minimize  the 
remaining  utility.  Then 


"a'"’  ifj  (’  - 


^i  ,j  ,k. 


This  will  be  a drawdown  curve  if  plotted  against  W, 

and  as  defined  form  a composite  measure  of  the  design's 
throughput  capacity,  GOS,  survivability,  flexibil ity,  and  interoperability. 
These  last  two  "ilities"  are  included  in  a subjective  manner  through  the 
initial  construction  of  the  communications  requirements  matrices  (subsection 
1;  in  the  equations  for  U.  and  U,  let  a-  • ,,  range  over  all  requirements). 

Each  design  will  have  an  associated  cost  which  can  be  determinpH 
from  the  data  of  subsection  2 above.  Now  imagine  the  set  of  all 
possible  designs  within  a specific  DCS  alternative;  then  exclude 
from  consideration  all  designs  whose  cost  exceeds  D,  the  predicted 
DCS  budget  constraint.  The  remaining  set  of  designs  is  almost  astronomically 
large;  nonetheless  we  imagine  measuring  U.  and  U (W)  for  each  design 

D d 

at  some  fixed  W.  For  each  design,  then,  we  have  a point  in  a two-dimensional 
space  as  shown  in  Figure  7.  Thus,  we  have  a mechanism  which  displays  the 
set  of  all  admissible  designs  within  one  specific  DCS  alternative.  The 
mechanism  establishes  a 1-1  correspondence  between  each  design  and  its 
performance,  the  points  (U.  , U,(W)).  As  an  aside,  the  reason  that  no  points 
are  plotted  in  the  upper  pie  shaped  region  is  that,  by  the  definitions, 

U^(W)  must  be  equal  to  or  less  than  for  any  design. 

The  performance  characteristic  of  a DCS  alternative  can  nnw  he 
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Figure  7.  The  pairs  (Uj),  Ua(W))  for  the  set  of  admissible  designs 
within  a specific  DCS  alternative  at  fixed  W 
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defined  in  terms  of  Figure  7.  Since  a rational  choice  is  to  pick  the 
points  of  maximum  performance,  the  performance  characteristic  is  just  the 
locus  of  extreme  points  (Uj^,  Ug(W))  in  the  E - NE  sector  of  the  figure. 

This  is  plotted  in  Figure  8.  The  set  of  points  forming  this  line  can  be 
thought  of  as  representing  the  subset  of  dominant  designs  within  the 
specific  DCS  alternative. 

A mechanism  is  now  apparent  both  for  choosing  among  DCS  alternatives 
and  for  selecting  within  the  chosen  alternative  a specific  design 
(desirable  hierarchical  structures  and  mix  of  media).  As  an  example. Figure 
9 shows  a hypothetical  case.  Clearly  alternative  1 is  preferable  regardless 
of  the  desired  mix  of  U|^  and  Ug(W).  Choosing  this  mix  then  points  to  a 
specific  (in  terms  of  hierarchical  structure,  mix  of  media,  etc.)  design 
within  the  chosen  alternative  by  the  1-1  correspondence  between  design  and 
performance. 

c.  The  Problem.  The  foregoing  discussion  has  introduced  the 
concepts  and  definitions  necessary  to  define  the  DCS  technical  planning 
problem  in  concrete  terms.  The  total  problem  is  a sequence  of  subproblems. 

(1)  Subproblem  a.  Prediction  of  Demands.  Referring  to  the 
definitions  contained  in  subsection  1,  it  is  necessary  to  predict  for  the 
desired  point  in  time: 

{U^,  U2,  •••,  U^} 

{(i.x.,y^.)  : i = 1,2,  •••,  I}^  ; k = 1,2,..-,K 
k = 1,2,---,K 

^®i j^k 
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Figure  8 


The  performance  characteristic  of  a 
specific  DCS  alternative 
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Requirements  for  interoperability  and  flexibility  under  crisis 

conditions  are  contained  in  the  construction  of  these  matrices. 

(2)  Subproblem  b.  Prediction  of  Technology  and  Cost.  Referring 

to  the  definitions  contained  in  subsection  2,  the  following  predictions  are 
« 

required  for  the  desired  point  in  time: 


C = (U,  f^,  c^,  d^,  x^,  y^)  : ^ = 1,2,  •••,  L} 

® V V V 

L = {([i.j],  f..  c.  .,  d.  .)  : i,j  = 1,2,  •••} 

I 9J  I 9 J I 9j 

S = {(n,  f^,  c^,  d^)  : n = 1,2,  •••,  N} 

G = {(t,  f^,  c^,  d^,  x^,  y^)  : t = 1,2,  ••*,  1} 

D = f(T,-). 
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There  will  be  several  versions  of  each  of  the  above 
sets;  one  for  each  conceivable  (and  feasible)  variation  of  functional 
capability  and/or  implementation  scheme  for  the  set  in  question.  One 
possible  variation  v^ould  consider  the  problem  of  making  lease/buy  decisions 
in  the  DCS.  Such  decisions  can  be  handled  by  assuming  each  of  the  various 
possible  alternatives,  appropriately  modifying  the  CER's  in  each,  and 
determining  the  consequences  in  terms  of  the  performance  characteristic 
introduced  earlier. 

(3)  Subproblem  c.  Formulation  of  DCS  Alternatives.  This 
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problem  is  adequately  discussed  in  the  DCS  Architectural  Issues  subsection. 
Here  we  simply  point  out  that  it  is  analytically  related  to  the  assumptions 
made  in  the  problems  of  (1)  and  (2)  above. 


(4)  Subproblem  d.  Network  Analysis.  Given  the  predictions  of  (1) 
and  (2)  above,  and  a specific  DCS  alternative  from  (3)  above,  find  the 
performance  characteristic  of  that  alternative. 

(5)  Subproblem  e.  Management.  It  is  likely  that  in  the  multitude 
of  DCS  alternatives,  many  will  be  so  close  to  each  other  in 
performance  characteristics  that  clear  cut  quantitative  choices  cannot  be 
made.  In  fact,  a particular  DCS  alternative  may  not  be  uniformly  dominant 
under  variations  in  W or  D.  In  this  case  the  range  of  competing  DC5 
alternatives  must  be  submitted  to  further  analysis  with  respect  to  other 
DCS  'il ities."  Many  of  these  ilities  can  only  be  evaluated  subjectively; 
hence,  management  must  exercise  its  prerogative  in  choosing  between  the 
remaining  alternatives  and  a desired  (U.  , U,(W)). 

D Q 

(6)  Subproblem  f.  Refinement.  The  solutions  to  the  preceding 
five  problems  narrow  down  the  range  of  far-term  DCS  choices  by  specifying 
a partitioning,  a switching  technology,  a hierarchical  structure,  and  a 
mix  of  media.  An  approximate  sizing  is  also  found.  At  this  point  more 
detailed  work  can  begin  on  the  development  of  transition  plans  and  hard- 
ware related  issues  of  reliability,  maintainabil ity.  and  availability.  Issues 
of  flexibility,  interoperabil ity,  and  restorabil ity,  as  well  as  security  may 
also  be  studied  in  some  depth  since  the  issues  have  been  appropriately 
scoped  into  the  context  of  a fairly  specific  future  DCS  architecture. 

This  report  stops  short  of  considering  these  issues  beyond  this  point. 
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III.  APPROACH 

"...  let  us  first  of  all  understand  the  problem  as  a whole. "[6] 

I.  SCOPING  THE  PROBLEM 

The  preceding  chapter  has  defined  the  DCS  technical  planning 
problem  in  terms  of  four  technically  oriented  subproblems  given  in  section 

II,  3,c.  Problem  e depends  on  management  to  select  one  (or  more)  DCS 
alternative(s)  out  of  a set  which  may  be  indistinguishable  under  the 
four  preceding  technical  problems.  Having  focused  the  DCS  alternatives 
to  a small  number  by  these  efforts  now  allows  detailed  engineering  work 
to  commence  with  the  selected  alternative  as  a basis,  as  indicated  in 
problem  f. 

The  sequence  of  subproblems  in  DCS  technical  planning  was  arrived 
at  through  consideration  of  "high  level"  architectural  issues.  We 
suspect  that,  realistically,  these  issues  cannot  be  addressed 
independently,  and  so  one  of  our  problems  is  to  develop  a methodology 
which  can  consider  their  interaction.  In  order  to  accomplish  this  the 
problem  must  be  stated  in  concrete  terms,  i.e.,: 

a.  What  is  the  objective  of  planning?  Ours  is  to  maximize  the 
DCS  performance  characteristic  (Figure  8). 

b.  What  are  the  variables?  Ours  are: 

(1)  DCS  alternatives,  defined  in  section  II,  3,b;  this 
includes  partitioning  alternatives  and  switching  technology  alternatives 
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defined  in  section  II,  3, a. 

(2)  Hardware  assumptions,  given  in  the  sets  of  section  II,  2. 

The  range  of  hierarchical  structures  and  mix  of  media  issues  are  embedded 
in  these. 


c.  What  are  the  constraints?  Ours  are 

(1)  A total  DCS  Budget,  D,  given  in  section  II,  2. 

(2)  Demands  for  service,  given  in  the  requirements  matrices 
of  section  II,  1. 

‘ (3)  The  adversary's  attack  resources,  W,  given  in  section  n,  3. 

It  does  not  seem  reasonable  to  attempt  a single  computer  program  to  solve 
this  problem.  The  reasons  are  straightforward  enough.  There  are  an 
extremely  large  number  of  possible  DCS  alternatives,  and  the  generation  of 
the  performance  characteristic  (or  an  approximation)  for  a single  alter- 
native requires  the  solution  of  a sequence  of  network  design  problems 
of  large  size. 

A preferable  approach  would  use  an  interaction  between  man  and 
machine.  In  this  approach  a man  would  select  from  files  on  the  machine  a 
specific  DCS  alternative  and  a set  of  hardware  assumptions  for  analysis. 
The  machine  would  then  compute  the  corresponding  performance  characteristic 
for  inspection  by  the  man.  By  iterating  this  procedure  a heuristic  model 
involving  both  man  and  machine  is  created.  Such  an  approach  allows  the 
design  of  a computer  program  to  solve  the  simpler  problem  below. 

Given: 

a.  A specific  DCS  alternative 

b.  A specific  set  of  hardware  assumptions 
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c.  The  requirements  matrices 

d.  The  DCS  budget  constraint 

e.  The  adversary's  attack  resources. 

Find: 

The  associated  performance  characteristic. 

This  problem  is  very  similar  to  the  work  ordinarily  performed 
within  R700.  The  differences  are  in  degree.  To  solve  the  DCS 
architectural  develop^Tient  problem,  it  is  necessary  to  increase  the  range 
of  assumptions  that  can  be  made  in  alternatives  and  hardware,  and  automate 
the  overall  evaluation  process.  This  can  be  done  through  the  performance 
characteristic  measurement  and  the  interactive  procedure  mentioned  above. 
2.  METHODOLOGY 

The  present  network  design  tools  being  used  for  DCS  System  Design 
planning  efforts  have  been  developed  over  a number  of  years  and  have 
played  an  important  role  in  the  continuing  upgrading  and  optimizing  of 
DCS  plans  [8,9,10].  However,  in  considering  the  total  spectrum  of 
future  architectural  concepts  that  are  under  consideration,  it  may  well 
be  necessary  to  develop  specific  tradeoffs  for  which  modelling  tools 
have  not  yet  been  developed.  The  remainder  of  this  section  discusses  the 
requirements  and  characteristics  needed  for  such  architectural  design 
tools. 

a.  The  Range  of  DCS  Designs.  The  problem  under  consideration  is 
the  discovery  of  the  major  design  features  (say  a more  detailed 
architectural  plan)  of  the  future  DCS.  This  DCS  may  comprise  one  or 
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several  large  scale  communication  network(s);  this  is  a parameter  to 
be  discovered.  If  more  than  one  network  is  indicated,  the  user  community 
served,  possible  gateways,  the  type(s)  of  service  provided, and  the  amount 
of  traffic  handled  by  each  network  must  be  discovered.  For  each  network 
in  the  future  DCS,  the  most  efficient  division  of  functions  between  the 
access  area  and  backbone  designs  must  be  uncovered;  e.g.,  the  hierarchical 
definition.  This  involves  selecting  the  number,  loading, and  functions  of 
local  switches,  concentrators,  backbone  switches  and  their  interconnections 
in*a  cost  effective  way.  Naturally  this  means  that  CER's  must  be  developed 
for  each  class  of  hardware, with  the  independent  variables  being  the 
implementation  scheme,  loading,  function, and,  where  applicable,  number  of 
terminations. 

The  principal  technical  issues  in  the  network  desion  oroblem  can 
be  seen  as  the  following: 

(1)  Statistical  multiplexing  of  two  generic  types  of  traffic 
needs  to  be  considered  in  a network  design  context.  The  two  generic 
traffic  types  are  described  by: 

(a)  "Long"  holding  times;  i.e.,  traffic  which  is  best 
matched  by  circuit  switched  networks. 

(b)  "Short"  holding  times;  i.e.,  traffic  which  is  best 
matched  by  packet  switched  networks. 

Note  that  some  specific  traffic  types,  e.g.,  facsimile,  may 
be  mapped  into  either  of  the  generic  types  above  and  the  economic  impact 
on  DCS  design  of  such  options  merits  consideration. 

(2)  Access  area/backbone  design  interaction  needs  to  be 
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studied  In  the  absence  of  externally  (and  possibly  arbitrarily)  imposed 
constraints.  This  issue  may  have  significant  impact  on  both  the 
economics  and  the  survivability  of  the  DCS,  and  certainly  is  a key  issue 

in  using  network  design  tools  to  deduce  future  hardware  developments 
needed  in  the  DCS. 

(3)  Satellite/terrestrial  networks  design  interaction  needs 
to  be  studied  and  can  only  be  reasonably  approached  by  a design  tool 
which  simultaneously  considers  both.  A more  realistic  attitude  would 
be  to'consider  a single  network  comprising  both  terrestrial 

and  satellite  components. 

(4)  The  network  design  tools  necessary  to  scope  the  far  term 
DCS  must  be  capable  of  coping  with  roughly  1,000  traffic 

sources  (user  installations)  and  perhaps  2,000  to  3,000  nodes 
(major  hardware  devices,  exclusive  of  terminal  equipment  and  local 
switches) . 

The  complexity  of  this  problem  is  indicated  in  Figures  10,  11 
and  12.  The  figures  are  developed  from  the  user  installation  outward 
into  the  DCS.  Suppose,  for  example,  that  there  were  1,000  user  installations 
to  be  serviced.  Then  there  are  the  same  number  of  local  switches 
interconnected  through  an  as-yet  unknown  number  of  concentrators  and 
backbone  switches.  Also  unknown  are  the  numbers  of  satellites  and 
satellite  terminals  and  the  richness  of  the  interconnection  matrix  for 
all  hardware.  The  problem  is  further  compounded  by  not  knowing  the 
optimum  functional  characterization  of  the  hardware  or  the  best  partitioning 
(see  Figures  5 and  6).  In  any  problem  of  this  magnitude,  it  is  necessary 


38 


Figure  10.  Interconnection  possibilities  for  a local  switch 
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Figure  11.  Interconnection  possibilities  for  a concentrator 
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that  the  major  features  be  abstracted  and  heuristic  approaches  developed 
to  find  a snlution. 


b.  A Heuristic  Approach.  An  obvious  first  approach  to  the  numerical 
problem  above  is  initially  to  assume  overly  large  populations  of  hardware 
in  each  class.  Likewise,  assume  the  richest  possible  interconnection 
amongst  all  hardware.  Once  these  assumptions  are  made, CEP's  are  available 
for  each  type  of  hardware,  and  conmuni cations  requirements  are  given;  the 
problem  is  then  solvable,  in  principle,  by  employing  the  theory  of  multi- 
commo'dity  flow  networks.  Thus  computer  algorithms  can  be  developed  which  operate 
by  finding  a sequence  of  flow  equivalent  networks,  with  each  successive 
network  costing  less  than  the  preceding.  Physically, what  happens  is  that 
many  of  the  interconnecting  links  are  removed, thus  obviating  the  need  for 
some  of  the  initially  assumed  hardware;,  flows  are  rerouted;  links  are 
resized; and  hardware  functions  are  turned  off  (or  on)  in  such  a way  as 
to  find  a minimum  cost  network.  If  the  minimum  cost  is  less  than  the 
budget  constraint, the  process  can  be  iterated  to  increase  service  and  cost. 

In  the  case  of  either  all -linear  or  all -constant  cost  functions 
for  each  element  in  the  network,  the  theory  for  accomplishing  the  above 
is  conceptually  straightforward  and  precise.  Thus  either  Dijkstra's 
algorithm  [11]  or  a minimum  spanning  tree  algorithm  [12]  could  be  employed 
in  principle.  In  practice  neither  of  the  cost-function  situations  holds. 

This,  compounded  by  the  magnitude  of  the  problem,  forces  consideration  of 
using  the  above  computer  algorithms,  in  conjunction  with  heuristic 
approaches  and  gradient  techniques,  to  find  locally  optimum  solutions  in 
a reasonably  short  time. 
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A flow  chart  depicting  the  interrelationships  of  the  various 
technical  problems  and  a first  cut  approach  for  handling  the  overall 
issue  is  shown  in  Figure  13.  The  first  four  boxes  at  the  top  of  the 
figure  represent  data  collection  exercises  discussed  in  section  II. 

Each  of  these  may  be  done  independently,  but  must  conform  to  the 
mathematical  requirements  of  the  computer  model  which 
manipulates  the  data.  The  data  gathered  represent  a morphological  base 
covering  the  foreseeable  range  of  future  DCS  alternatives.  It  is  in  an 
unorganized  form  however;  i.e.,  it  does  not  constitute  a communications 
system,  only  the  components.  An  analogy  would  be  a menu  from  which  to 
choose  and  arrange  a dinner. 

The  next  box,  "SELECT  A SPECIFIC  DCS  ALTERNATIVE."  is  a human 
activity.  Here  the  human  selects  a consistent  subset  out  of  the 
morphological  base  and  the  machine  is  then  required  to  evaluate  the 
selection.  Thus,  it  is  important  that  the  data  in  the  morphological  base 
be  formatted  in  a manner  consistent  with  both  machine  requirements  and 
the  human's  need  for  subjectively  organized  labelling.  The  formats  of 
section  II  should  fill  both  needs. 

The  box,  "SET  UP  AN  INITIAL  RICHLY  CONNECTED  NETWORK,"  is  the 
first  step  in  the  machine  activity  for  evaluating  the  given  DCS  alternative. 
If  machine  memory  and  computation  time  permit,  the  initial  network  should 
be  completely  connected.  Otherwise  algorithms  to  aggregate  or  "cluster" 
the  user  installations.,  thereby  reducing  the  number  of  hardware  devices,  will 
be  required.  Efficient  clustering  will  depend  on  the  DCS  alternative  to 
be  evaluated. 


PLOT  (Ub,  Ua(W)) 
FOR  PRESENT 
ALTERNATIVE 


USE  NETWORK  AUG- 
MENTATION AL60- 
RITHM  TO  GENERATE 
A MORE  SURVIVABLE 
OFSIGN.  FIND  Uh 


Figure  13.  Flow  Chart  for  DCS  Architectural  Development/Evaluation 
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The  box,  "USE  MINIMUM  COST  NETWORK  DESIGN 


ft 


can  be 


developed  from  the  network  design  techniques  presently  used  at  DCEC. 

Major  extensions  required  are  the  ability  to  design  integrated  (voice/ 
data)  networks,  increasing  the  scope  to  handle  access  area/backbone 
tradeoffs,  satellite/terrestrial  tradeoffs,  and  multiple  networks  with 
associated  gateway  and  budget  allocation  problems. 

The  remaining  boxes  are  used  to  develop  the  performance 
characteristic,  and  associated  sequence  of  network  designs,  for  a given 
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DCS  alternative.  The  basic  idea  is  to  derive  successively  more  survivable 
designs  from  the  first  design  which  maximized  Uj^.  To  accomplish  this  the 
machine  games  the  "design-attack-redesign-attack-..."  situation  in  the 
lower  loop.  The  point  of  view  adopted  in  this  loop  is  that  the  value  of 
attacked  resources  in  the  present  design  is  freed  up  for  reallocation  in 
the  next  design. 


IV.  EPILOGUE 


The  statement  of  the  DCS  architectural  development/evaluation 
problem  given  in  section  1 1. 3,  c and  the  flow  chart  for  the  process  of 
Figure  13  should  be  used  as  guidelines  in  the  DCS  architectural  efforts. 
The  problem  statement  is  admittedly  incomplete,  but  it  provides  a 
necessary  starting  point  for  improvement.  Any  improvements  in  the 
prob'lem  statement  must  be  couched  in  concrete  terms  since  an  equivocal 
problem  statement  can  only  result  in  equivocal  solutions. 

The  overall  architectural  development/evaluation  problem  consists 
of  a number  of  subproblems  needing  further  development,  namely: 

1.  SUBPROBLEM  A,  PREDICTION  OF  DEMANDS 

Crisis  communications  requirements  should  be  determined  in  the 
formats  of  section  11,  1.  The  requirements  should  not  be  referenced  in 
any  way  to  the  physical  DCS  since  such  predictions  can  be  regarded  as 
"self  fulfilling  prophecies."  Requirements  predictions  should  be  made  in 
the  context  of  foreseeable  needs  for  information  exchange  among  using 
installations  under  crisis  conditions.  The  DCS  should  then  be  planned 
to  meet  these  needs.  Solving  this  problem  is  an  essential  part  of  the 
total  and  will  require  the  continuing  effort  of  a number  of  experts.  It 
is  recommended  that  a study  to  generate  these  data  be  initiated. 

2.  SUBPROBLEM  B,  PREDICTION  OF  TECHNOLOGY  AND  COST 

The  range  of  possible  hardware  devices  with  which  the  DCS  could 
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be  constructed  is  very  large.  A convenient  means  of  aggregating  the 
possibilities  is  given  in  the  formats  of  section  II,  2.  These  formats, 
along  with  the  mechanism  of  Figure  13,  will  allow  DCS  planners  to  deduce 
. the  functional  nature  of  preferable  hardware  for  the  DCS  and  initiate 

development  action  when  the  indicated  hardware  is  not  already  available. 

By  modifying  the  CER's  to  reflect  lease/buy  options,  the  consequences 
in  terms  of  the  total  system  can  be  determined.  This  problem  too  is  an 
essential  and  difficult  piece  of  the  total  and  should  be  staffed 
accordingly.  A study  in  this  area  should  be  initiated. 

3.  SUBPROBLEM  C,  FORMULATION  OF  ALTERNATIVES 

DCS  alternatives  cannot  be  assessed  unless  they  are  couched  in 
concrete  terms.  The  data  formats  suggested  for  subproblems  a and  b 
provide  a mechanism  for  describing  both  the  range  and  specific  choices 
for  DCS  alternatives  in  an  unequivocal  way.  As  mentioned  above,  the 
problem  herein  is  incomplete.  Efforts  to  improve  the  problem  statement 
by  adding  new  dimensions  amount  to  adding  to  the  range  of  alternatives. 

The  obvious  difficulty  is  in  adding  new  dimensions  to  the  problem  state- 
ment in  such  a way  that  they  are  concrete;  the  new  subproblems  posed  are 

I 

I amenable  to  technical  solution,  and  the  total  problem  remains  tractable. 

\ It  is  difficult  to  pin  down  how  this  can  be  done.  What  can  be  done  is 

f • 

i to  insist  that  outputs  from  the  formulators  be  well-defined  and  that  the 

, overall  technical  planning  mechanism  remains  self  consistent. 

4.  SUBPROBLEM  D,  NETWORK  ANALYSIS 

Network  analysis  is  a major  element  of  the  architectural  development/ 
evaluation  mechanism.  A realistic  assessment  of  a given  DCS  alternative 
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can  be  made  only  by  using  this  tool.  The  existing  models  will  require 
considerable  modification  and  extension  to  create  the  mechanism  of 
Figure  13.  Continuing  research  will  be  necessary  to  improve  these 
tools,  since  network  problems  of  such  large  size  dictates  that  heuristics 
have  to  be  employed.  In  addition,  the  design  tools  are  expandable  in 
that  new  dimensions  will  be  added  as  the  problem  statement  is  improved. 

These  considerations  point  to  the  need  for  the  implementation  and 
improvement  of  design  tools/processes  such  as  indicated  in  Figure  13. 

A process  which  is  not  understood  cannot  be  controlled.  The 
first  step  in  improving  the  DCS  design  process  is  documentation.  The 
publication  of  study  results  is  insufficient.  Documentation  concerned 
with  how  the  overall  process  works  is  essential  for  visibility  (goal- 
orfented  behavior)  and  to  elicit  concrete,  constructive  criticisms  for 
improving  the  process.  Similar  documentation  is  necessary  for 
individual  efforts  contributing  to  the  overall  process.  The  intent  is 
to  produce  documentation  of  the  operational  procedures  and  assumptions 
used  in  the  technical  efforts  supporting  management.  Specifically,  such 
items  as;  problem  definition,  approach,  data  formats  (when  interface 
with  other  problem  areas  is  required),  and  relation  of  the  part  to  the 
whole,  should  be  published  for  each  of  the  subproblems.  The 
documentation  should  be  updated  on  a continuing  basis  as  the  planning 
mechanism  and  factors  evolve. 
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